Skip to content

fix: add parent-dir permission checks to symlink() and link()#341

Draft
toddr-bot wants to merge 1 commit intocpan-authors:mainfrom
toddr-bot:koan.toddr.bot/fix-symlink-link-perms
Draft

fix: add parent-dir permission checks to symlink() and link()#341
toddr-bot wants to merge 1 commit intocpan-authors:mainfrom
toddr-bot:koan.toddr.bot/fix-symlink-link-perms

Conversation

@toddr-bot
Copy link
Copy Markdown
Collaborator

What

Add missing parent-directory permission checks to symlink() and link().

Why

With set_user() active, symlink() and link() would succeed in restricted directories (e.g., mode 0555) where they should return EACCES. Every other directory-modifying operation — mkdir, rmdir, unlink, rename — already checks write+execute permission on the parent directory. This gap meant permission-checking tests could pass incorrectly when using symlinks or hard links.

How

Added _check_parent_perms($path, 2|1) calls to both __symlink and __link, following the same pattern used by __mkdir, __rmdir, and __unlink.

Testing

  • New subtests in t/perms.t: verify both operations fail with EACCES on read-only parent dir and succeed on writable parent dir
  • Full test suite passes (94 files, 1588 tests — only pre-existing fh-ref-leak.t failure)

🤖 Generated with Claude Code

Both symlink() and link() were missing write+execute permission checks
on the parent directory of the destination, unlike mkdir/rmdir/unlink/rename
which all enforce this. With set_user() active, these operations would
succeed in restricted directories where they should return EACCES.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant